And as a quick crack (but there are more elegant ways) we can
4) substitute the byte '75' at :0041DA55 with a 74, transforming
the jne in a je, as usual, inverting the jumps. Jump if equal!
Since I have been (blandly) critized by fellow scholars for
speaking all the time of more elegant ways and yet presenting
only simple ways, here IS a more elegant crack for this code:
4) Substitute with a new ONE the first TWO instructions:
:0041DA4E 66C70538A04B000100 mov word ptr [004BA038],1
and leave all the rest unchanged:
:0041DA57 6A00 push 00000000 ;zero
:0041DA59 6A6C push 0000006C ;ID
:0041DA5B 6811010000 push 00000111 ;WM_COMMAND
*****************************
As you can see, we have just moved the flag '1' inside our
location, instead of comparing and jumping away as in the
original code and in the quickly cracked one. Estilo muchissimo
elegante.
Since this lesson was thought as +HCU material, here is the
result of the work on it made by (some of) my students:
JANUARY 1997: THIS PART OF LESSON 9.3 HAS BEEN MODIFIED (OR
ADDED) BY THE +HCU STUDENTS OF UNIT 4
Let's finish our cracking of the nagscreens of the whole PaintShopPro family with version 4.1, which is the most recent we know of. I am using here PSP.EXE 1.151.488 bytes from 1 Sep 1996, fetch it through the archies. We will crack this shareware program BETTER than the registered version, since we will completely eliminate any nagscreen and we'll not ever have the welcome screen that REMAINS inside the registered version. We'll do this 'in a hurry', since it is not +ORC speaking, but some of h
enough about the 'dead listing' method to be able to follow. No
Winice in our hands, Ladies and Gentleman, We never used it on
this program. (Well... we actually did, before reading 9.3, but
it brought us nowhere, for this crack we (almost) DID NOT,
following +his instructions)
1) Get the 'dead listing' of psp.exe (it's huge)
2) Load it inside a fast wordprocessor
3) Find the string 'Purchasing' at :00406710
4) short after 'Purchasing' the only location compared and loaded
is location [004BC218]. Let's call it 'BINGO' and let's hope
it'll work.
5) this location is handled inside a small part of the code
:00406290 to :004067B5, this reduces the more than one million
bytes to 1317 bytes we'll have to examine, not bad.
6) Let's print this nagging part of the code and let's feel it
a little
7) Let's see the possible cracks we could think of (we repeat,
here is not +ORC's but his students at work, we are not perfect).
Well, let's try along, what happen if we substitute a ret at
:00406535?
:00406535 C390909090 ret and nops
Nothing at all.
And what if we substitute here
:004064F6 8B4508 mov eax, [ebp+08]
:004064F9 85C0 test eax, eax
:004064FB 7504 jne 00406501
:004064FD 33C0 xor eax, eax
:004064FF EB03 jmp 00406504
:00406501 8B4020 mov eax, [eax+20]
:00406504 6A00 push 00000000
... the instruction
:004064FB 7504 jne 00406501
with the instruction 7500 (or 90 90)?
MOST BRILLIANT!
Now we XOR ANYWAY THIS AX without caring for ax+20. The nagscreen
is defeated? Not really... the nagscreen has been passed ON THE
BACKGROUND, where it still remains when you shut the 'main'
window of the program... the nag protection is somewhere there,
looking at us square in the faces... but where?
+gthorne here: since i had already seen the production version
of paint shop pro, i realized that it also had a nag screen - not
per se, but a splash screen (the very same screen without the
buttons to push and the 'number of days elapsed' warning). what
this means is that it is very possible that the screen
(regardless of what version we are running) could be intermingled
with the rest of the code, and not fully existing within a
call. This does not proved it, just allowed the possibility.
Poking around, and being playful, i fired up snap32 and grabbed
the nagscreen window and saved it for future reference.
The next thing i did was check into the help screen area of Paint
Shop Pro. Often in shareware programs there is a HELP ABOUT, or
a HELP REGISTER section. Sometimes those places give away good
info needed (or just plain useful) in the crack routine.
Something that stood out in the help area was the paint shop pro
version statement. It seemed to be identical to the printed
version as seen on the nag screen. That means one of two things:
either the version number string was just typed in twice, or more
likely, just another call to a function: PSP_VERSION() or
somesuch.
What that means for the crackist should be pretty clearly a way
to locate the protection routine. Since the word SHAREWARE shows
up in both version calls, it can be scanned for pretty easily
with either that or the word VERSION itself.
Then, once i felt i had done enough scouting the territory, I ran
WDASM and grabbed myself a dead listing. Scanning for SHAREWARE,
I found a couple easy references to it... one being a data string
that I promptly blanked out and the other being in the text that
comes up on the nagscreen itself. WELL WELL...
This is the nagscreen result here:
* StringData Ref from Data Obj ->"This is a shareware version
of "Paint Shop Pro."
|
:00406B64 6810A34B00 push 004BA310
:00406B69 8D4DEC lea ecx, [ebp-14]
Okay, running the program again, and firing softice (old friend)
i immediately saw that the version checking routine no longer
tacked on the word SHAREWARE in either the nagscreen or in the
help box.. thus proving the version call to be just that.. a call
(as suspected).
Immediately, something else came up that I was not expecting, the
location of most of the program in memory was exactly the same
as seen with softice that it was hardcoded into the disassembly.
What i mean by that is that where softice was reporting
0137:0043FAD1 for a location in memory, identical data was
reported at location :0043FAD1 on the disassembly.
Now, talk about convenient!
Simply enough, i breakpointed in softice with a few locations i
had located in the disassembly, and voila... landed smack in the
middle of the nagscreen data.
It was do-able with soft-ice alone, but tracing into the maze of
nested calls in PSP really wasn't worth my time.
Line-by-line'ing it, it was simple to watch the nagscreen build
itself call by call, and NOP or alter JZ's & JNZ's to JMP's (74's
and 75's become EB's) so that the nagscreen lost more and more
functionality.
Then came a little work - not too much, but some things were a
little funny. Notice the BITBLT in the nagscreen creation code.
I had tried to scan for some of the standard SHOWWINDOW calls
with softice and in the disassembly, but not one was to be found
where it needed to be. Apparently PSP was using some other method
of showing the screen... and a simple graphics memory copy (known
to those who follow Micro$oft as a BitBlt) was apparently the
modus operandi.
Some of the text was already in place before the BitBlt, so here
is our reason that some of the nagscreen was not being done as
we watched with the debugger... it was being written to a
backbuffer before being copied as a whole window before being
blitted to the screen. This, for those of you new to graphics
programming, is how people make smooth animation that does not
flicker... all of the animating is done in the background and a
whole screen is blitted at one time rather than by bits and
pieces (you can tell which programs do not do this very easily
since they have images that seem to disappear or flicker wrong
in odd places on the screen)
There were not many calls in that area, and only the ones that
referenced string data or the bitblt itself could be effectively
nop'ed out.
Here is where i basically stopped the work, since i was having
trouble locating what CALLED the nagscreen area.
The reason we are getting the ghost window in the back (notice
it's size is EXACTLY the same as the nagscreen, is that windows
is being instructed by some window create command to block off
the rectangular space for the screen even though the graphic
interior does not get written.
The crack that puts the nagscreen on the backgrpund is invaluable here since the ghost window does not have a way to be removed without paint shop pro closing (which
cleans up nicely for itself on exit).
Now we need to locate the call that creates the window in the
first place and nop it or whatever... there is probably a nicer
way to do all this (if you work at it, you can probably jmp past
all the functions i nop'd - taking care not to leave unmatched
pushes or pops which ruin the flow of the program - at some point
in the nagscreen area
The funny part of all this is that our cracked version will be
better than the registered version since the registered version
has a splash screen anyway - and ours does not :)
Using all of this knowledge later can actually benefit us in a
different way... we can actually use all of the techniques (since
we already know where the nagscreen is) on the executable of the
full version as well.
Since it has no nag functions, it is a smaller executable and
cracking it will give is a nagless, splashless (eg. screenless)
version of paint shop pro that is smaller (i.e. better and more
functional) than by just cracking the shareware version.
I find that funny somehow :)
So here is all the rest you need:
Let's have a look at the VERSION subroutine that is called both
in the nagscreen and the HELP screen:
* StringData Ref from Data Obj ->"4" ;FIRST DIGIT OF VERSION 4.01
